The present invention relates to electronic data processing, and more particularly to the redirection of windows for improved display on a computer display screen.
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. The following notice applies to the software and data as described below and in the drawing hereto: Copyright(copyright) 1998, Microsoft Corporation, All Rights Reserved.
Graphical user interfaces are today the standard manner in which people interact with computers of almost every kind. From simple beginnings, many devices and layouts have evolved to permit the presentation of data in a variety of ways designed to make it easier to understand and more intuitive.
One of the earliest techniques of graphical interfaces was the use of multiple windows drawn on a single screen for displaying outputs fromxe2x80x94and inputs toxe2x80x94multiple sources at once. Although multiple windows can arise from a single program on a computer, the usual screen includes windows from different programs executing independently of each other on the computer, or even on different computers.
The presence of multiple display windows on the same physical screen requires control over the manner in which the windows interact with each other. With some operating systems, the windows are provided by a window manager that obtains display information from multiple applications and manages the manner in which they are presented on a display screen. Some windows may be enlarged to cover the entire screen. The other windows are then covered by this enlarged window. At other times, many windows may be displayed on the screen at the same time, some overlapping or obscuring others. Usually, there is a primary window that is essentially a container of child windows and is itself a child of the desktop, called a top level window. The window manager keeps track of the z order of the windows. In other words, just like a stack of papers, the windows are stacked in a virtual xe2x80x9czxe2x80x9d direction, which defines which windows will be on top of and obscure other windows.
Since the computer system may be processing information related to many of the applications with corresponding windows, it may be desirable for a user to see what is going on in more than one of the applications. Previously, users could resize windows, but this would result in perhaps only seeing a portion of the desired information, unless the information presented in a window is also resized, at which point, it may become too small to see. Larger screen sizes and multiple monitors have also been used to get around such a problem, but they are very expensive and take up much desktop space. Events in some applications may cause the window of information related to it to rise to the top of the pile, thus possibly obscuring other windows, and the contents of the window to be refreshed by the application. However, these window raising events can also raise the ire of a user who is concentrating on a project in the window currently on top.
With the large number of windows which may be open in today""s multitasking world, there are also performance problems associated with window manipulation, such as moving a window or resizing it. In the Microsoft Windows 98(copyright) and NT operating systems, applications write to the screen only the portion of their associated window that is not obscured by other windows. Windows produced by applications normally paint via a handle to a display device context (DC) retrieved by calling BeginPaint or GetDC. By drawing via the display device context handle, the application draws directly to the screen and thus the system does not have a copy of the visual bits drawn by the window. Since a window may be partially or completely obscured by other windows on the screen, the visual bits cannot be reliably extracted by reading the bits from the screen buffer. When moving a window, there are many messages passed back and forth between the application and window manager to repaint the window as different portions of it become viewable due to a window move or resize. Repainting by the application is required, even though there may be no activity in the corresponding application. Thus, a window move, resize or other manipulation that results in obscured portions of other window being uncovered causes the application to perform work to generate such portions. In many game applications, constructs called xe2x80x9cspritesxe2x80x9d are used to represent graphical elements, which move within a window. The system recomposes them without need for the application to repaint them.
There is a need to provide an efficient and fast mechanism for managing the display and manipulation of frequently moving or animated windows on a viewing screen. There is also a need for the management of windows to provide the ability to view more information associated with obscured windows. There is yet a further need to allow applications to access and manipulate the visual bits of windows in different manners.
Output from an application or other program running in a windowing environment is redirected from the application to a bit map where it can be further manipulated prior to being displayed from a display screen buffer. The redirection can be performed on the windows of new applications as well as existing legacy applications. A style bit is associated with each window from applications which are to be so redirected. By providing selected windows with redirection bit maps, performance can be enhanced by not requiring each application to regenerate portions of windows which may be uncovered during manipulation of the windows by a presentation manager.
Further parameters may be associated with display of the window to provide position and size information and to provide special effects. Some special effects, such as transparency are identified by an alpha value and a color key, which enables further programs to manipulate the window in its associated bit map to make it appear transparent. The alpha value allows specification of a range of transparencies from totally transparent to opaque as desired. One or more application program interfaces (APIs) provide the ability to specify the transparency, positioning, color key, size and other attributes as well as whether or not the window is redirected. This API may be utilized by the application, or may be used via a user interface to allow the user to select a desired window to redirect. Thus, an application can control the transparency, positioning, color key, size and other attributes by using the API.
An independent application or a system shell utilizing the redirection functionality can to create a 3 dimensional or other representation of the applications running on a computer. This can be accomplished by instructing the system to redirect the drawing performed by legacy applications"" windows, then reading from the redirection bit map, applying a 3D or other transform to it, and further drawing it in its own window. Thus, the application will not appear on the screen as it normally would, but would appear in a transformed form. Therefore, the redirection functionality can also be used to design a new user interface (UI) (3D or otherwise) using existing legacy applications.
The color key attribute can be used to specify the transparency applied to an identified color. In one example, the face of a clock window may be of a certain color which is specified as completely transparent. Only the hands of the clock and perhaps numerals identifying the hours are visible on a display screen. This allows it to overlay other windows without adversely affecting the viewing of information of such overlayed windows. The areas of the window that are completely transparent can also be clicked through thus allowing the end user to work with the overlayed window while keeping the layered window on top.
By specifying the transparency of an entire window generated by an application, it can essentially be seen through, to allow viewing of activity in windows provided by other applications if desired. Dialogs for background tasks can also be transparent. Further, by having selected windows in bit maps, they may be more easily repainted simply by obtaining them from their bit maps rather than having the corresponding applications repaint them directly, which would consume much system resource. Still further, effects may be applied to the bit map without having to modify any of the drawing related code in an application.